在實務上，不少團隊在撰寫 User Story 或討論需求驗收時，常會混淆「Acceptance Criteria」和「Acceptance Test」的概念。有些人認為只要列好驗收條件就算測試，有些則希望一開始就寫出完整的驗證腳本。

這樣的誤解常導致兩種情況：

• 對需求的理解只是「看起來講好了」，卻沒有明確共識
• 測試撰寫變成開發後的補件，而非需求探索的一部分

本篇將透過定義說明、實際範例、方法論關聯與實施建議，幫助你和團隊釐清這兩者的不同角色，並知道如何在各種流程中妥善運用，讓需求更清楚、交付更穩定。

Acceptance Criteria 是什麼？

Acceptance Criteria（驗收準則）是用來說明「這個需求何時可以被接受為完成」的一組條件。它是針對功能結果的高層描述，不包含技術實作細節。

主要目的是讓開發團隊、PO、業務、測試等利害關係人，對需求怎樣就做完有一致理解。

通常以條列形式描述，也可使用 Gherkin 語法。例如：

購物車功能

• 使用者可以從購物車中移除商品
• 商品移除後總金額會更新
• 若購物車為空，顯示「購物車為空」訊息

Acceptance Test 是什麼？

Acceptance Test（驗收測試） 是根據驗收準則，具體執行步驟與預期結果的測試流程。它是可以手動執行或自動化的測試，用來驗證系統是否符合接受條件。可由 QA 或開發人員撰寫，也可透過工具自動化執行。

通常使用 Gherkin 語法，包含 Given-When-Then 的結構。例如：
Scenario: Remove item from cart
Given I have 2 items in my cart
When I remove one item
Then I should see only 1 item in my cart
And the total amount should update accordingly

(1) 比較說明

(2) 例子對照（同一功能）

Acceptance Criteria 和 Acceptance Test 如何搭配使用

圖 8-1 AC 和 AT 如何搭配使用

在實務上，推動 BDD或SBE時，我們通常會採用一種「三層轉換流程」，讓團隊在釐清需求、定義完成標準、到撰寫測試的過程中，能夠逐步建立共識。這三層分別是：

(1) 使用者故事（User Story）
這是從使用者角度出發，描述一個希望達成的目標或需求。例如：「身為常旅客，我希望能夠儲存我的信用卡資料來加快購票流程。」

(2) 驗收條件（Acceptance Criteria）
這一層列出什麼情況下，我們可以說這個需求已經「完成」了。這些條件通常是以商務語言撰寫，不涉及太多技術細節，例如：

• 系統需支援儲存 VISA 信用卡
• 使用者可以在下次購票時，選擇已儲存的 VISA 卡來完成交易
  這些條件幫助團隊對「完成的標準」建立明確共識。

(3) 驗收測試（Acceptance Test）
在第三層，團隊會將驗收條件進一步轉換成可以執行、可以驗證的具體測試案例。這些案例會包含實際情境與操作，並用明確輸入與預期結果來驗證條件是否成立，例如：

• 使用者儲存了一張 MasterCard（卡號以 2017 開頭）
• 但這張卡不符合條件（只支援 VISA），因此在下次購票時不應出現在可選卡片列表中

雖然很多團隊會說：「那我們一開始就寫 Gherkin不就好了？」但以下是為什麼在實務中不建議在初期直接跳到測試層：

(1) 團隊語言還沒對齊
Gherkin 語法雖然清晰，但對非技術人員如 PO、業務來說仍不自然，會讓需求討論變成語法辯論，而非重點聚焦在業務價值上。

(2) 需求還在探索期
初期的討論重點應該是「你要什麼」，而不是「怎麼驗證」。驗收條件能幫助大家先共識完成標準，再來討論驗證方式。

(3) 容易誤解「測試就是需求」
若直接從測試開始寫，可能會讓人誤以為「測試驗過就好了」，而忽略測試本身是為了服務需求探索的工具，而非目的本身。

這樣的三層設計，讓需求（為何要做）、完成標準（做到什麼程度才算完成）、以及驗證方法（怎麼確定完成）都能有系統地展開討論。這不僅能幫助開發與測試對齊，更能讓非技術人員參與設計過程，提高需求品質與交付信心。

案例故事：導入「信用卡儲存功能」的三層轉換實踐

讓我們用一個案例，展示貫通三層流程的狀況：

(1) 背景與挑戰
某電商購票平台近期收到大量客服反應：
「每次購票都要重填信用卡資訊，對於常旅客來說非常不便，特別是在手機上操作時容易輸入錯誤。」

PM 收到這些訊息後，提出了一個新功能：「讓使用者可以儲存信用卡資訊，方便下次直接使用。」聽起來簡單，實際上卻充滿風險與限制：

• 風控限制：只能儲存 VISA 卡（合作金流公司要求）。
• 介面設計挑戰：要怎麼讓使用者知道哪些卡能儲存、哪些不能？
• 測試場景複雜：需處理成功儲存、儲存錯誤、卡片過期等情境。

團隊面臨的核心挑戰是：「我們要怎麼確保這個功能被開發出來時，每個人理解的一致、驗證方式一致、交付結果一致？」

(2) 導入策略：使用三層轉換流程（User Story → AC → AT）
團隊決定採用 BDD/SBE 的「三層需求轉換流程」，一步步推進：

A. 使用者故事（User Story）
在 PM 的帶領下，團隊進行了一場 需求澄清工作坊。PM 並沒有馬上展示解法，而是先問了一個問題：
「你們認為，為什麼使用者會想儲存信用卡？」

大家開始討論：

• 「節省時間」、「避免重複輸入」、「減少錯誤」…
• PO 補充：「但我們有風控限制，只能儲存 VISA。」
• QA 提醒：「那如果用戶儲存了 MasterCard 呢？系統應該怎麼處理？」

最後凝聚出這樣的使用者故事：
作為一名常旅客，我希望可以儲存我的信用卡資訊，這樣下次購票就能快速付款，不必重填。
這一段讓團隊理解了「為什麼要做」，而不只是「要做什麼」。

B. 驗收條件（Acceptance Criteria）
緊接著，團隊共同討論出「什麼情況下這個功能才算完成」。這裡出現了大量具體情境與條件：

• 只允許儲存 VISA 卡
• 儲存卡片需基本格式正確（卡號、效期、CVV）
• 下一次購票時，僅應顯示已儲存的 VISA 卡
• 儲存非 VISA 卡時，應給予友善錯誤提示

為了讓條件更具體，PO 把這些條件寫成貼在白板上的黃色便條紙，和大家逐條對齊語意。

QA 提出關鍵觀點：
「這些條件聽起來合理，但要怎麼驗證它們？我們是不是應該也討論『會發生什麼事』？」
於是團隊自然地進入第三層：撰寫驗收測試。

C. 驗收測試（Acceptance Test）
由 QA 撰寫初版 Gherkin 測試，並邀請 RD、PO 進行共筆審查：

Scenario: 儲存不支援的 MasterCard 不應顯示於付款畫面
Given 使用者新增了一張 MasterCard（卡號為 2017 開頭）
When 該使用者進行下一次購票
Then 系統不應顯示該卡於付款方式選單中

Scenario: 成功儲存 VISA 並可用於付款
Given 使用者新增了一張有效的 VISA 卡（卡號為 4556 開頭）
When 使用者下一次購票時進入付款頁面
Then 該卡片應出現在可選擇付款方式中

QA 設計了兩組帳號來跑測試，一組儲存 VISA、一組儲存 MasterCard。工程師根據這些場景設計對應邏輯與錯誤提示。

(3) 團隊互動亮點
這次合作過程中，展現了許多有價值的互動方式：

互動情境 具體行動 效果
開發前釐清語意 PM/PO 用便條紙逐條列出驗收條件，由 QA 確認是否可驗證 減少開發後來回修正與語意誤會
Gherkin 共筆審查 QA 負責草擬測試場景，PM 補充錯誤流程，RD 確認可實作性 測試場景同時涵蓋 happy path 和 edge case
PO 觀測開發畫面 在開發階段，PO 會進會議室看開發畫面、協助對齊驗收條件 即時對焦「這樣算完成嗎？」的問題，少了多次來回驗證

(4) 最終效果與回饋
A. 正面成果：

• 團隊在開發前對「完成標準」非常清楚，交付更順利。
• 測試範例成為活文件，之後每次金流功能異動時，都能直接回頭檢查測試場景。
• 客服也使用這些驗收條件中的「錯誤提示」做為 FAQ 文案。

B. 持續學習：

• 初期 Gherkin 撰寫時，大家語言不太對齊，經過 2–3 次共筆後才逐漸習慣。
• 發現「寫測試」的真正價值，不在驗證程式碼，而是讓需求與交付品質具體對齊。

這個案例不只是技術練習，更是一次團隊學會如何讓需求更有品質、讓測試更有價值的歷程。過程中的三層轉換：
為什麼要做？→ 要做到什麼程度？→ 怎麼知道有做到？

不僅幫助交付成功，也逐漸形塑出一種跨角色共創品質的文化。